Source-to-Source Transformations for WCET Analysis: The CoSTA Approach

Worst-case execution time (WCET) analysis is concerned with computing upper bounds of the maximum computation time of a program. This is indispensable for the development of safety-critical realtime systems, where missing a deadline can have disastrous consequences, including the loss of lives. Tools for WCET analysis typically analyze the object-code of a program since this is the code which is actually executed. Simultaneously, they usually rely on user-provided annotations such as loop-bounds or execution frequencies of program statements in order to be effective. From the perspective of a programmer, it is often more adequate to provide such information on the source code level than on the object code level. This, however, introduces a gap between the WCET annotation and the WCET analysis level. Within the CoSTA project (Compiler Support for Timing Analysis) we are aiming at bridging this gap. Fundamental to this is to provide appropriate new compiler support allowing to transform source code annotations into equivalent object code annotations. In this paper we outline the approach taken in the CoSTA project to achieve this. In this project, which has recently been started, the compilation process is decomposed into a high-level machine-independent and a low-level machine-dependent two-stage process. Here, we will focus on the first stage of this process, the high-level source-to-source compiler and the annotation framework. 1 Background and Motivation For safety-critical real-time systems the timing behavior is as important as the correctness of the calculations, since the consequences of missing a deadline can be equally catastrophic as an incorrect calculation, causing even the loss of lives. Before deploying such a system it is thus indispensable to ensure that the system meets in addition to its functional constraints also its timing constraints. Determining the worst-case execution time (WCET) of a program as precisely as possible is essential for this. Intuitively, the determination of the WCET of a program is equivalent to the search for the most time-consuming path in the control flow graph of the ? This work has been supported by the Austrian Science Fund (Fonds zur Förderung der wissenschaftlichen Forschung) under contract P18925-N13. program. An early approach for WCET analysis is called timing schema [10]. In this approach, the execution time of each basic block is assumed to be a constant and the number of iterations of each loop construct to be bounded by an upper limit, while branches are replaced by the max()-function. A more sophisticated approach for supplying path information to the WCET calculation tool is based on linear flow constraints [11]. In this approach the program flow information often called flow facts is expressed as a system of inequalities that forms the input of an integer linear programming (ILP) problem that can be solved efficiently by a variety of tools [8]. This method is also called implicit path enumeration technique (IPET). It is implemented by commercially available tools like AiT [2] and Bound-T [4]. While it is often possible to automatically extract flow facts from the program code, it is usually necessary to require the programmer to (additionally) manually annotate the program with appropriate flow facts. On the one hand, this is necessary because the overall problem is undecidable (such as the determination of loop bounds). On the other hand, the programmer might have additional knowledge about the input data. State-of-the-art tools perform the WCET-calculation on the object code level, which is as close as possible to the code that will eventually run on the target hardware. These tools expect that any user annotations are provided in the object code. This, however, is very demanding for a programmer and errorprone. Moreover, it implies to reassure the correctness of the annotations after each compiler run during the development phase.